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[57] ABSTRACT 

Disclosed are a method and a system for transmitting a 
message or data packet from a single sender (21) to a 
plurality, Le, a group of receivers, usually called mul- 
ticasting, within a conventional unicast transmission 
network, Le. a network basically not equipped to handle 
such multicast transmissions, consisting of a plurality of 
subnetworks (22-24). The nodes or gateways (25-29) 
connecting the subnetworks maintain tables of multicast 
receiving stations (or groups of such) and the header of 
each message includes information defining the groups 
of the addressed multicast receiving stations. 

16 Claims, 5 Drawing Sheets 
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network (the MPTN); the gateways are connected via 

INTER-DOMAIN MULTICAST ROUTING the third subnetwork 18, e.g. a Transmission Control 

Program/Internet Protocol (TCP/IP) network. 

DESCRIPTION a key function of the MPTN gateways 16 and 17 is to 

1. Field of the Invention 5 route messages from their source (e.g., the client appli- 
In computer networks, routing protocols are used to cation 12) to the destination (e.g., the server application 

distribute information that allows determination of how This problem is difficult for the following reasons, 

to send a data packet or a message from any point in that A path between the source and destination must be 

network to its intended destination. In many cases, a found that satisfies the requirements of the application 

data packet or message is sent from a single source, the 10 (e.g., security, speed, reliability), 

sender, to a single receiver; this is usually called unicast- The MPTN may be very large, with many subnet- 

ing. Today's computer networks have elaborate routing works and gateways. This can result in a very complex 

protocols to support or assure safe, fast, and reliable network topology, and therefore complex routing deci- 

execution of such unicast transmissions. If a data packet sions need to be made at the gateways, 

or message must, however, be sent from a single sending 15 Due to link and node failures, or the installation of 

source to a group of receiving stations within a network new equipment, the topology, and thus the correct 

- usually called multicasting - it is very inefficient, if at routing decisions, change in real time, 

all possible, to rely on traditional unicast routing proto- To solve these problems, MPTN gateways make use 

cols for this purpose. For this, the present invention 0 f the routing protocol mentioned above that was stan- 

provides a solution; it relates to multicasting, in particu- 20 dardized by ^ international Standards Organization, 

lar to a method of multicasting messages in a complex called the Inter-Domain Routing Protocol (IDRP). 

network that is originally equipped only for unicast IDRP defines the formats and procedures of a protocol 

transmission. for routmg from a smgle source to a single destination in 

2. Background and Objects of the Invention network of t x ^ size However) 
Existing state-of-ttie-ad routing protocols, such as the 25 mRp dQes nQt mu i ticas t m g f that is, delivery of 

Inter-Domam^Routiiig Protocol ODRP), as disclosed a m from a ^ le source to ^ le destinations. 

. S h n t J™*™* v On the other hand, multicasting is essential in MPTN 
s-Teleconimumcations and Information Exchange f a nmnber of reasons . F irst,1ome subnetworks sup- 

between Systems— Protocol for the Exchange Inter- . _ u: ^ , A , ' t . A . * 

Domain Routing Information Among Intermediate 30 Port multicasting and\ Aerefore apphcations running 

Systems to Support Forwarding of ISO 8473 PDUs", °|\ those Networks take advantage of this feature. In 

ISO/DIS CD 10747, 1991, being standardized by the °^ CT to P rovide connectivity to such applications, mul- 

International Standards Organization, ISO, provide a tlcastm § m o ust be supported in the internetworking envi- 

framework for routing unicast packets, that is, packets ronme ^ Second, some MPTN control protocols are 

sent to a single destination. 35 based on multicasting. For example, protocols for locat- 

Often, a key requirement of computer networks in m « a resourc e require that a search for that resource be 

general, and of applicant's Multi-Protocol Transport distributed to all gateways attached to subnetworks in 

Network (abbreviated MPTN in the following) specifl- which it might be located. 

cally, is to allow the multicasting of data packets, which Some examples of the problems associated with mul- 
are sent from a particular source to a group of destina- 40 lasting in an internetwork environment are now de- 
mons. Generally speaking, this invention gives a solu- scribed making reference to the simple MPTN illus- 
ion to this requirement by teaching a method of and a trated in FIG. 2. In this example, a multicast is initiated 
system for multicasting using a set of new protocols in by an application in subnetwork W (21) that should be 
combination with existing routing protocols (e.g. delivered to destinations in subnetworks X (22) and Z 
IDRP) to support multicasting in a computer network 45 ( 24 )* There are no destinations in subnetwork Y (23). 
of arbitrary size and topology. It has characteristics The problems associated with such an operation in* 
which make it suitable for such an environment that are elude: 

not found in any existing multicasting protocols. I* -S not acceptable to generate separate (unicast) 
In the following, background and objects of the in- messages to all destinations since this would create an 
vention shall be described in more detail. It should be 50 unnecessary load on the MPTN resources. For exam- 
understood, however, that the invention is not in any pie, in FIG. 2, such a unicast strategy would necessitate 
way restricted to use within the type of network de- that one message for each destination be sent on the link 
scribed hereinbelow. Further examples can be found in between gateway A (25) and gateway B (26) instead of 
other pads of the description. just a single multicast message, 

A widely used protocol set such as IBM's Multi- 55 It is not acceptable to multicast the message to every 

Protocol Transport Network provides connectivity-to subnetwork in the MPTN. In the example, subnetwork 

computer applications, regardless of the network to Y (23) should not receive a multicast destined only to 

which they are attached. Thus, as illustrated in FIG. 1, nodes in subnetworks X (22) and Z (24). Although not 

two applications attached to different subnetworks in illustrated by the example, it is clear that in a large 

the same MPTN 11 can communicate. As shown in 60 MPTN with many subnetworks and many different 

FIG. 1, a client application 12 attached to a first subnet- multicast groups, such a flooding strategy would not be 
work 13, e.g. a NetBIOS subnetwork (a trademark of acceptable. 

the applicant), can communicate with a compatible A given packet should only be multicast once to a 
server application 14 attached to a second subnetwork given subnetwork. In the example network, there are 
IS, e.g. a System Network Architecture (SNA, which is 65 two paths from gateway B (2d) to subnetwork X (22), 
also a trademark of the applicant) subnetwork. MPTN via gateway D (28) and via gateway C (29) direct. Sub- 
gateways 16 and 17 are required to join the three differ- network X (22) should, however, only receive a single 
ent subnetworks 13, 15, and 18 into a single logical copy of the multicast from the source in subnetwork W 
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(21). This rule must hold regardless of the number of 
gateways attached to subnetwork X (22), or the number 
of paths between a source and a particular destination 
subnetwork. This is important to minimize the load 
placed on subnetworks due to multicast traffic, and to 5 
avoid duplication of packet delivery which may neces- 
sitate error recovery, protocols for some applications. 

Prior Art 

For a better understanding of the invention, solutions 10 
for multicasting messages in other environments, and 
existing solutions in internetworking environments will 
be reviewed. 

Local Area Networks (LANs) J5 

LANs are a very special type of subnetworks since 
they naturally support a broadcast function, such that a 
single message is easily delivered to all nodes. The most 
common LAN multicast strategy is therefore to broad- 
cast messages, and let each attached computer Miter 20 
those messages not required by local users. An example 
is given by S.E. Deering and D.R. Cheriton in "Mul- 
ticast Routing in Datagram Internetworks and Ex- 
tended LANs", ACM Transactions on Computer Sys- 
tems , Vol. 8, No. 2, pp. 85-1 10, ACM, May 1990. How- 25 
ever, such a strategy seems unsuitable for a large inter- 
network, as previously explained. It should also be men- 
tioned that essentially the same observations hold for 
Metropolitan Area Networks (MANs). 

When LAN segments are interconnected by bridges, 30 
these can selectively filter LAN messages so that they 
are only broadcast on segments where at least one node 
is a destination for a multicast. These protocols work as 
follows (see Deering and Cheriton, cited above, for 
variations on this basic algorithm): 35 

1. Group members broadcast their existence on the 
LAN to which they are attached. These broadcasts are 
forwarded by bridges onto all LAN segments so that all 
bridges can learn tile location of group members. 

2. When a multicast packet for a group is received, 40 
only bridges on the path to one or more members of that 
group forward the packet. Thus, flooding of all LAN 
segments for each multicast is avoided. 

A restriction of such LAN-based multicasting is that 
no loops are allowed in the topology, i.e. there cannot 45 
be multiple paths via bridges between any two LAN 
stations. This is required since otherwise the simple 
forwarding scheme used by the LAN bridges would 
result in packets being broadcast forever around any 
such loop. Such a scheme is unsuitable for multicasting 50 
in a large internetwork since all traffic would be forced 
to take the same path through the internetwork thereby 
creating an unacceptable load on the involved links. 
Algorithms exists which allow loops to exist in the 
LAN topology, but a single set of bridges is selected 55 
that form a loop-free spanning tree for forwarding mul- 
ticasts. Thus, all multicast traffic is still forced to follow 
a single path along the branches of the spanning tree. 

Multicasting in the Internet ^ 

Multicasting algorithms exist that work with routing 
protocols used in Internet Protocol (IP) networks. IP 
networks provide routing and relaying of packets 
(called datagrams) over a general topology network 
consisting of LANs, point-to-point links, and even sub- 65 
networks such as X.25. An IP internetwork consists of 
a collection of such subnetworks interconnected by IP 
routers. 



The following routing protocols used in IP networks 
are all based on a distance- vector (sometimes also called 
path-vector) routing scheme like that used in IDRP: 

Routing Information Protocol (RIP), as described by 

C. L. Hedrik in "Routing Information Protocol", RFC 
1058 (Request for Comments), NIC (Network Informa- 
tion Center), June 1988. 

Hello Routing Protocol, disclosed by D.L. Mills in 
"Experimental Multiple Path Routing Algorithm", 
RFC 981, NIC, March 1986. 

Border Gateway Protocol (BGP), described by K. 
Lougheed and Y. Rekhter in "Border Gateway Proto- 
col (BGP)", RFC 1163, NIC, June 1990. 

Gateway-Gateway Protocol (GGP),as disclosed by 
R.M. Hinden and A. Sheltzer in **DARPA Internet 
Gateway", RFC 823, NIC, September 1982, 

As will be apparent later, the present invention pro- 
vides a solution directly applicable to all networks 
based on the above (and equivalent) routing protocols, 

IP multicast algorithms have been developed primar- 
ily for use with the Routing Information Protocol as 
disclosed by C.L. Hedrik, cited above, but are usable 
with the other distance-vector routing algorithms as 
well. IP multicast algorithms (see, e.g. S.E. Deering and 

D. R. Cheriton, cited above; S.E. Deering: "Host Exten- 
sions for IP Multicasting", RFC 1112, NIC, August 
1988; L. Hughes and P. Thomlinson: "A Multicast In- 
ternetwork Routing Algorithm". Proceedings of the 
IFIP WG 6.4 Conference on High Speed Networking, 
18-22 March 1991, Berlin, pp. 183-200; D. Waltzman, 
C, Partridge, and S.E. Deering: "Distance Vector Mul- 
ticast Protocol", RFC 1075, NIC, November 1988) are 
all variants of the Reverse Path Broadcasting algorithm 
described by Y.K. Dalai and R.M. Metcalfe in "Reverse 
Path Forwarding of Broadcast Packets", Communica- 
tions of the ACM, Vol. 21, No. 12, pp. 1040-1048, 
ACM, December 1978. This algorithm is similar to the 
LAN multicast algorithm in that a spanning tree is used 
to distribute the multicast packets, however it contains 
additional features to solve some of the problems associ- 
ated with LAN multicasting. In brief, the algorithm 
works as follows (see S.E. Deering and D.R. Cheriton, 
cited above, for a more detailed description): 

1. Multicast packets are initially broadcast to all sub- 
networks in the internetwork. Packets are broadcast on 
a least-cost spanning tree. When a router receives a 
multicast packet from some source **S", it knows that it 
is on the spanning tree for multicasts originating from S 
if its routing tables indicate that it can reach node S with 
a lower cost than all other routers attached to a given 
subnetwork (this information is available in the normal 
IP routing tables). If so, that router forwards the mul- 
ticast packets on the subnetwork in question. It was 
shown by S.E. Deering and D.R. Cheriton, cited above, 
that this algorithm results in the multicast packet being 
distributed to each subnetwork in the internetwork with 

minimum cost. 

An obvious improvement of this scheme compared to 
the LAN multicasting schemes is that while here the 
multicast spanning tree is fixed for a given source, it is 
not the same for all sources. Thus multicast traffic is 
distributed over many different paths in the network. 

2. In order to avoid broadcasting multicast packets to 
subnetworks that do not have members in the specified 
group, a scheme is used whereby routers that receive a 
multicast for a particular group that do not lie on a 
branch of the multicast tree that leads to any members 
of that group discard the multicast (there is obviously 
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no need to forward it) and report to the predecessor in 
the multicast tree that this branch of the tree may be 
pruned. This process begins with routers attached to 
"leaf subnetworks" (subnetworks that are at the end of 
their respective branches owl the tree), and works its 5 
way up the branch as far as possible to restrict the distri- 
bution of multicast traffic to where it is required. 

The IP multicast schemes have the following draw- 
backs: 

Initially, multicasts from a given source to a given 10 
group must be broadcast to the entire internet until the 
multicast tree for that source-destination pair is pruned. 

The scheme requires that information used for prun- 
ing the multicast trees be discarded after some time so 
that new members that loin the network on a previously 15 
pruned tree branch will eventually start receiving the 
multicasts. Thus, multicasts trees are continuously re- 
built and repruncd, creating considerable overhead on 
the network links and processing nodes. 

Multicast trees exist for each source-multicast group 20 
pair. That is, a separate logical multicast tree exists for 
each different source that multicasts to a given group. 
Titus routing nodes may have to maintain an extremely 
large database for pruned multicast trees. 

For these reasons such protocols or algorithms seem 25 
unsuitable for use in the MPTN and similar architec- 
tures. A useful algorithm should be able to utilize the 
routing capabilities of gateways which have no mul- 
ticast intelligence. 

In some more detail, the following goals or objects of 30 
the invention can be identified as requirements for pro- 
viding multicast service: 

1. Multicast packets must not be broadcast to all sub- 
networks, and in fact should be restricted to being sent 
only to subnetworks that have a multicast group mem- 35 
ber. 

2. Each multicast packet must be delivered exactly 
once to each destination subnetwork (i.e. duplicate mul- 
ticast packets must not be created). 

3. The protocols should not require any centralized 40 
elements. They should be completely distributed. 

4. The protocols should not require computation of a 
spanning tree from a centralized database. 

5. Routing decisions for multicast packets must be 
flexible. Distribution of all multicasts over a fixed span- 45 
ning tree for example is not acceptable. 

6. The number of packets distributed must be mini- 
mized. In particular, it is not acceptable to generate a 
separate unicast packet for each destination. 

7. The cost of distributing the multicast packets must 50 
be minimized. Thus, a good path must be taken from the 
multicast source to each destination. 

SUMMARY OF THE INVENTION 

In brief, the present invention achieves the above 55 
objects by a method and a system for multicasting a 
message from a sending station to a plurality of receiv- 
ing stations within a conventional unicast message 
transmission network using existing protocols by, at 
least in certain nodes within the network, maintaining 60 
tables of subnetworks with multicast receiving stations 
or tables of multicast receiving stations and by including 
appropriate routing information in the header of mul- 
ticast messages, as further defined in the claims. 

With this invention, a solution is presented that, when 65 
used in combination with distance-vector routing proto- 
cols such as the standard OSI IDRP routing protocol, 
disclosed in ISO "Information Technology — Telecom- 



munications and Information Exchange between Sys- 
tems — Intermediate System to Intermediate System 
Intra-Domain Routing Protocol for Use in Conjunction 
with the Protocol for Providing the Connection", 
ISO/DIS 10589, 1990, or any other similar protocol, 
such as those used in IP networks referenced above, 
supports multicasting in large internetworks. This solu- 
tion is also usable with link-state routing protocols, such 
as OSPF developed for IP networks (described by J. 
Moy in "OSPF Version 2", RFC 1247, NIC, July 1991) 
and the OSI IS-IS protocol (described in ISO/DIS 
10589, cited above) and are thus applicable to a wide 
range of internetworking environments. Within the 
invention, three new types of protocols are presented: 

1 . for the distribution of routing information based on 
network topology and the location of multicast group 
members, and for the creation of routing tables using 
this information; 

2. for efficiently forwarding multicast packets to all 
members of a multicast group given the routing infor- 
mation front tile first step; and 

3. for enabling the multicast protocols to be used in 
the MPTN environment 

Details and examples of the invention will be de- 
scribed in the following in connection with the draw- 
ings. 

THE DRAWINGS FIG. 1 illustrates a multi-protocol 
transport network (MPTN) comprised of three 
subnetworks (already discussed with the prior art 
above); 

FIG. 2 illustrates an example for another MPTN (also 
already discussed above); 

FIG. 3 illustrates an example of the information 
learned by gateways from attached subnetworks; 

FIG. 4 illustrates a detail in a subnetwork, namely all 
nodes with a common address prefix in such a subnet- 
work; 

FIG. 5 illustrates various nodes with a given address 
prefix in different subnetworks; 

FIG. 6 illustrates the so-called MPTN split net ID 
support 

FIGS. 2 and 3 show essentially the same arrange- 
ment, the reference numbers are chosen such that the 
last digit of each number identifies the same part in each 
figure, i.e. "21" in FIG. 2 is the same part as "31" in 
FIG. 3. 

DETAILED DESCRIPTION 

The following section is divided into four pads. The 
first pad, entitled "Routing Information", describes the 
routing information that is distributed and the tables 
that are created for routing multicast packets. The sec- 
ond pad, entitled "Multicast Packet Forwarding", de- 
scribes the procedures for using the created tables to 
route multicast packets. Then, in the third pad, entitled 
"Multicast with Reduced Routing information:", a de- 
scription is given of how the amount of routing informa- 
tion required for the multicasting protocols can be re- 
duced. Finally, in part four, entitled "MPTN Use of 
Multicast", an example is given of how MPTN uses the 
protocols described in this invention. 

Routing Information 

A brief description of the Inter-Domain Routing 
Protocol (IDRP) protocol is provided so that the inven- 
tion may be better understood. Further details can be 
found in ISO/DIS 10589, referred to above. 
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IDRP distributes routing information between gate- 
ways in so-called Update PDUs, i.e. Update Protocol 
Data Units. Update PDUs contain the following fields 
that are relevant to the invention. 

1. Reachability Information: this field specifies the 
resources that can be reached along the path specified in 
this Update PDU. It can be the address of a specific end 
system, or it can be the prefix common to the addresses 
used by a set of end systems. All systems whose address 
contains a given prefix reside in the same subnetwork, 
and therefore this prefix uniquely identifies this subnet- 
work. A type field is defined in the reachability infor- 
mation which indicates that the reachability informa- 
tion is an address prefix (type=0). Thus, different types 
of reachability information could be distributed in Up- 
date PDUs by defining a new type code. 

2. Quality of service: this specifies properties like 
cost, delay, and security implications of using the rout- 
ing information in this update PDU. 



10 



15 



The reachability information in an Update PDU con- 
taining groupids consists of only the groupids and (one 
of) the address prefix(es) unique to the end systems in 
the subnetwork reporting the groupids, so that all gate- 
ways will be able to build an association between the 
subnetwork prefix and the groupids reachable in that 
subnetwork. 

The Update PDU constructed in this manner is deliv- 
ered with the reachability information field unchanged 
to all gateways according to the existing IDRP proto- 
cols. Note that this Update PDU construction is al- 
lowed by the IDRP standard, and that no other changes 
to the Update PDU construction or distribution are 
required. 

In the example shown in FIG. 3, gateway C (39) 
would create an Update PDU with the following reach- 
ability information: prefix =X, groupid =G. Similarly, 
gateway E (37) would create an Update PDU with 
prefix =Z and groupid =G. Both of these Update 



3. Path: the routing information that specifies how to 20 PDUs would be distributed to all other gateways ac- 



reach the end systems identified by the prefix(es) in the 
reachability information. 

Based on received Update PDUs, gateways build 
routi ng tables, called Forwarding Information Bases 
(FIBs) in IDRP. For each destination (a destination is 25 
identified by a prefix received in an Update PDU, and 
may thus be a single node or a set of nodes), the next 
gateway on the path to that destination is stored (this is 
determined from the path field in the update PDU). 



cording to the IDRP protocol to allow all of them to 
learn the association between group G and subnetworks 
Xand 2. 

As reachability information changes (e.g., the prefix 
changes, or groupids are added or deleted), the changes 
are reported to the local gateways which use the normal 
IDRP routing protocols to update all MPTN gateways 
with the new information. 
Construction of Update PDUs as specified above 



Exactly one path for each prefix is stored for each 30 allows gateways to build an additional routing table 



unique set of quality of service parameters. This path is 
the one that can best provide the specified quality of 
service. 

In the invention, a new type of reachability informa- 
tion is defined, called a group identifier (groupid). A 
groupid is used to address a group of end systems that 
are to receive a particular set of multicasts. The grou- 
pid, which is chosen from the normal subnetwork ad- 
dress space, is therefore included as the destination 



which will be referred to as the Multicast Routing 
Table or MURT. The MURT contains for each groupid 
the list of prefixes for subnetworks containing members 
of that group, as learned from Update PDUs containing 
35 groupids. How the MURT is used for routing is ex- 
plained in the next section. 

In the system of FIG. 3, following the distribution of 
the Update PDUs as described above, each gateway 
would have a MURT entry for groupid G, identifying 



address of a multicast packet so that the proper group of 40 X and 2 as the prefixes of subnetworks in which group 



end systems is identified The end systems addressed by 
a particular groupid are not necessarily located in a 
common subnetwork. Selecting groupids from the stan- 
dard address space guarantees that they represent valid 
reachability information even for gateways which do 45 
not implement the multicast extensions described be- 
low. 

To support unicast inter-domain routing, subnet- 
works report the address prefix(es) shared by its nodes 
to gateways. These prefixes are used to create the Up- 50 
date PDUs as described above. In the invention, subnet- 
works also report all groupids reachable in that subnet- 
work. 

An example is illustrated in FIG. 3. In that figure, the 
subnetworks with prefixes X (32) and Z (34) also have 55 
end systems in group (9. They therefore report both the 
prefix and the groupid to the local gateways C (39) and 
E (37). Subnetworks W (31) and Y (33) do not have any 
groupids to report, so they report only their prefixes. 
Note that a given subnetwork may report multiple 60 
groupids and prefixes (not illustrated). 

IDRP Update PDUs are constructed as follows. Up- 
date PDUs not containing groupids are constructed as 
specified in ISO/DIS CD 10747, mentioned above. 
Update PDUs used to advertise reachability to groupids 65 
must contain the following information: 

An address prefix of the subnetwork, and 

one or more groupids for that subnetwork. 



members are located. 

The remaining IDRP routing tables (e.g., the FIB as 
described above) are constructed according to existing 
IDRP specifications. In particular the path information 
associated with all reachability information (including 
groupids) is stored in the FIB. 

Thus far in this section, the procedure for construct- 
ing a MURT using the OSI IDRP routing protocol has 
been described. This same procedure can be used with 
any distance-vector routing protocol, as e.g. described 
in the following references: C.L Hadrick, "Routing 
Information Protocol", RFC 1058, NIC, June 1988; 
R.M. Hinden and A Sheltzer, cited above; K. Loughead 
and Y. Rekhter, cited above; D.L. Mills, cited above. In 
all such protocols, Update PDUs are distributed to 
advertise reachability to a given address or address 
prefix. By associating groupids with each address pre- 
fix, a MURT can be constructed as described above. 

A MURT can also be constructed using link-state 
routing protocols such as those described in ISO/DiS 
10589, 1990 or in J. Moy, cited above. In those proto- 
cols, each gateway distributes reachability information 
in link-state PDUs, which provide information on the 
state of each link adjacent to that gateway, as well as all 
address prefixes directly reachable from that gateway. 
These link state PDUs are forwarded unmodified to all 
other gateways in the system. Therefore, by also includ- 
ing a list of groupids in the link state PDUs, a MURT 
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can be constructed associating the group with a list of 
address prefixes of subnetworks in which group mem- 
bers reside. Both distance-vector and link-state routing 
protocols create an FEB which is essentially equivalent 
to that created by IDRP. Due to this, the multicast 5 
forwarding algorithm described in the next section is 
also applicable to these environments. 

Multicast Packet Forwarding 

Conceptually, once the MURT is constructed as de- 10 
scribed in the previous section, routing of multicast 
packets is very simple. The MURT allows the subnet- 
works in which members of the multicast group are 
located to be identified. Furthermore, the IDRP FEB 
can be used to route packets to each of these subnet- I 5 
works. A copy of each multicast packet could simply be 
routed to each of these subnetworks. However, due to 
the MPTN requirements specified in the section entitled 
Summary of the Invention, above, regarding restric- 
tions on the number of distributed packets, the methods 20 
and algorithms specified in this section are an essential 
part of this invention. 

The invention also defines a Multicast Spanning-Tree 
Algorithm (MSTA) for routing multicast packets in an 
MPTN. The MSTA is also usable in other networks 25 
that provide routing information similar to that speci- 
fied in the previous section. 

To assist the reader in understanding, MSTA is pres- 
ented in an example before the detailed algorithms are 
given. 

The topology of the network used in this example is 
illustrated in FIG. 3. Using the protocols of the previ- 
ous section, the following routing tables are constructed 
at the respective MPTN gateways: 

35 



At gateway A (35) 

FIB (prefix: next hop on shortest path) 

address prefix W: addresses with this prefix are located 

in the local subnet (31) 
X: the next gateway on the path to the subnet containing 

addresses with this prefix is Gateway B. 
Y: gateway B 
Z: gateway B 
G: gateway B 
MURT (groupid: associated prefixes) 

groupid G: the prefixes associated with this groupid are 
X.Z 

At gateway B (36) 

FIB (prefix: next hop on shortest path) 

W: the next gateway on the path to the subnet 
containing addresses with this prefix is Gateway 
A. 

X: gateway C 
Y: gateway D 
Z; gateway E 
G: gateway E 
MURT (groupid: associated prefixes) 

groupid G: the prefixes associated with this groupid are 
X,Z 

At gateway C (39) 

FIB (prefix: next hop on shortest path) 

address prefix X: addresses with this prefix are located 

in the local subnet (32) 
W: the next gateway on the path to the subnet containing 

addresses with this prefix is Gateway B. 
Y: gateway D 
Z: gateway B 
G: local subaet (32) 
MURT (groupid: associated prefixes) 

groupid G: the prefixes associated with this groupid are 
X,Z 

At gateway D (38) 

FIB (prefix: next hop on shortest path) 

address prefix Y: addresses with this prefix are located 
in the local subnet (33) 



10 
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X: 
Zz 
G: 



the next gateway on the path to the subnet containing 
addresses with this prefix is Gateway B. 
gateway C 
gateway B 
gateway C 
MURT (groupid: associated prefixes) 

groupid G: the prefixes associated with this groopid are 
X.Z 

At gateway E (38) 

FIB (prefix: next bop on shortest path) 

address prefix Z: addresses with this prefix are located 

in the local subnet (34) 
W: the next gateway on the path to the subnet containing 

addresses with this prefix is Gateway B. 
X: gateway B 
Y: gateway B 
G: local subnet (34) 
MURT (groupid: associated prefixes) 

groupid G: the prefixes associated with this groupid are 



The basic layout is shown in FIG. 3. In this example, 
G is the groupid of a multicast group which has mem- 
bers in subnetworks X (32) and Z (34). A source node in 
subnetwork W (31) sends a multicast to groupid G. 

MPTN gateway A (35) receives the multicast packet 
addressed to groupid G from subnetwork W (31). Its 
MURT entry indicates that the multicast is to be sent to 
the subnetworks with prefixes X (32) and Z (34). From 
its FIB, gateway A (35) determines that the next hop for 
both X and Z is gateway B (36). It therefore sends an 
MPTN multicast packet to gateway B (36) with the 
following fields: 

destination =G 

target subnetworks =X, Z 

data as specified in the original multicast packet 

Note that the target subnetworks field specifies all 
unique destination subnetworks for this multicast on a 
given path. Since both subnetworks X (32) and Z (34) 
are reached through gateway B (36), only a single 
packet is sent from gateway A (35) to gateway B (36) to 
accomplish the multicast 

Gateway B (36) receives the multicast packet speci- 
fied above. Since the target subnetworks are specified, it 
does not need to make use of the MURT. Note that this 
implies that only gateways that are attached to possible 
sources of multicast traffic need to maintain a MURT. 
All other gateways do not need to create this table. 
Gateway B uses its FIB to determine that the next hop 
for subnetwork X is gateway C (39) and for subnetwork 
Z (34) gateway E (37). It therefore sends an MPTN 
multicast packet to gateway C with the following fields: 

destination —G 

target subnetworks =X 

data as specified in the original multicast packet 

Note that the target subnetworks field only includes 
those subnetworks on this path. Subnetwork Z (34) is 
reached via a different path and is therefore not in- 
cluded in the multicast to gateway C (39). 

Similarly, gateway B (36) sends an MPTN multicast 
packet to gateway E (37) with the following fields: 

destination =G 

target subnetworks =Z 

data as specified in the original multicast packet 
Gateway C (39) receives the multicast destined for 
subnetwork X (32) to which it is attached. It therefore 
multicasts the packet to groupid G in subnetwork X, 
Similarly, gateway E (37) multicasts the packet in sub- 
network Z (34) to all members of groupid G. Thus the 
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multicast is delivered to all members of groupid G. The Set target— subnetworks to the list of prefixes associ- 

algorithms above meet all MPTN requirements for ated with that next hop. 

efficient multicast: Send the MPTN multicast including the groupid, 

1. The packet was only multicast in subnetworks that target—subnetworks, quality of service, and data to 
have a multicast group member (e.g., X and Z, but not 5 that next hop. 

Y). The MURT identifies the destination subnetworks. Note that in some cases the target subnetwork is 

2. Each multicast packet was delivered exactly once directly attached to this gateway and that the multicast 

to each subnetwork. The target subnetworks field of the is forwarded directly to that subnetwork in those cases. 

MPTN multicast is used to ensure that each subnetwork T . _ _ . _ , , /nTXT . , . . 

. . fit „ ... , List B — Procedure: Forward— MPTN— Multicast 
receives exactly one copy of the multicast. 10 

3. There are no centralized elements- The creation of This procedure is used by an MPTN gateway to 
the MURT, and the routing of multicast packets is com- forward a multicast packet received from another 
pletely distributed. MPTN gateway. 

4. The algorithms do not require computation of a Input: The MPTN multicast including the groupid, 
spanning tree from a topology database. 15 target— subnetworks, quality of service, and data as 

5. The multicast routing has all the flexibility of nor- created in procedure Initiate— MPTN_Multicast. 
mal MPTN routing. As shown in the example, the nor- Output: MPTN multicast packets to the next gate- 
mal IDRP FIBs are used to route multicast packets. ways on the path to the target, or a multicast di- 
This implies that different routes may be used for differ- rectly to target subnetworks that are directly at- 
ent multicast packets due to different quality of service 20 tached to the gateway. 

requirements and/or changing network conditions (to- For each prefix in the received target- subnetworks 

pology or load). list 

6. The number of packets distributed is minimized. A Use the prefix and the specified quality of service as 
multicast packet to several destinations (e.g., X and Z) is a key into the IDRP FIB to determine the next hop 
only sent as separate packets when the best routes to the 25 gateway on the path to that subnetwork, 
different destinations are not the same. In the example, Add this prefix to a list for the particular next hop. 
only a single packet was sent from gateway A to gate- For each next hop list created above 

way B, but gateway B sent individual packets to gate- Set target— subnetworks to the list of prefixes associ- 

ways C and £. ated with that next hop. 

7. The multicast packets are sent on the best route to 30 Send the MPTN multicast including the groupid, 
each destination according to the IDRP FIB. A unicast target— subnetworks, quality of service, and data to 
packet to one of the given destinations would follow the that next hop. 

same path as the multicast packet to that destination. Note that in some cases the target subnetwork is 
It is also important that only a single MURT entry is directly attached to this gateway and that the multicast 
created per multicast group. The multicast algorithms 35 is forwarded directly to that subnetwork in those cases, 
for the Internet Protocol described in the Prior Art w . . , n • T c • 
section of this disclosure require nodes to create mul- Multicast with Reduced Routing Information 
ticast tables with entries for each source-group pair In the multicasting scheme described in the previous 
(thus the number of entries is multiplied by the total sections, a MURT entry for a group is required at every 
number of sources compared to the MPTN scheme). 40 gateway that is attached to a potential source of mul- 
Having given the above informal description of the ticast traffic to that group. In large MPTNs with many 
MPTN multicast packet forwarding algorithm, the pro- groups, this may be undesirable. Therefore in this sec- 
cedures for multicasting are now specified in detail. One tion, an alternative scheme is described in which 
procedure is specified for the MPTN gateway that MURT entries for a particular multicast group need 
initially receives the multicast packet from a subnet- 45 only be maintained at gateways attached to subnet- 
work (List A), and one for intermediate MPTN gate- works with members in that group (other gateways may 
ways that forward multicasts received from other gate- optionally maintain these MURT entries). This scheme 
ways (List B). can potentially reduce the amount of storage required 
A „ a w . . - rnrr ^ y m , , . to support multicasting at the expense of optimal rout- 
List A-Procedure: Imtiate-MPTN_Multicast 5Q ^ M ^ be shown . ^ scheme described in this 

This procedure is used by an MPTN gateway that section is an integral part of this invention, and can be 

receives a multicast packet from a subnetwork. used in combination with, or in place of the previous 

Input: The subnetwork multicast packet which speci- scheme, 

fies a destination groupid, quality of service, and With this scheme, subnetworks report groupids and 

the data to be multicast. 55 address prefixes to adjacent gateways as was described 

Output: MPTN multicast packets to the next gate- in the section entitled Routing Information. These gate- 
ways on the path to the target, or a multicast di- ways must create MURT entries for the specified grou- 
rectly to target subnetworks that are directly at- pids. They must also create IDRP update PDUs as 
tached to the gateway. described in the addressed section. However, gateways 

Using the specified groupid as a key into the MURT 60 not attached to a subnetwork containing members of a 

obtain the list of prefixes for subnetworks containing particular groupid are not forced to maintain MURT 

members of the group. entries for that groupid. 

For each prefix in the list Forwarding of packets addressed to a groupid is done 

Use the prefix and the specified quality of service as as follows: 
a key into the IDRP FIB to determine the next hop 65 If a packet to be forwarded has the target subnet- 
gateway on the path to that subnetwork. works field set by a previous MPTN gateway, it is 

Add this prefix to a list for the particular next hop. forwarded according to the algorithm in List B. This 

For each next hop list created above can be done by all gateways since a MURT is not re- 
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quired for this algorithm (the destination prefixes are 
specified in the target subnetworks field). 

If a packet to be forwarded does not have the target 
subnetworks field set, and the destination address is a 
groupid for which a MURT entry is maintained at this 5 
gateway, the procedure for initiating an MPTN mul- 
ticast in List A is followed. 

If a packet to be forwarded does not have the target 
subnetworks field set, and no MURT entry exists for the 
destination address, the packet is forwarded point-to- 10 
point based on the IDRP FIB entry for that address. 

If only the gateways attached to the subnetworks 
with members of a group have a MURT entry for that 
groupid, the packet will be routed point-to-point to one 
of those gateways, which will then cause it to be mul- 15 
ticast to the remainder of the gateways. 

The above algorithm for routing with reduced infor- 
mation is illustrated with an example, again referring to 
the network depicted in FIG. 3. Using the protocols 
specified in this section, the following routing tables are 20 
constructed at the respective MPTN gateways: 



25 



At gateway A (35) 

FIB (prefix: next hop on shortest path) 

address prefix W: addresses with this prefix are located 

in the local subnet (31) 
X: the next gateway on the path to the subnet containing 

addresses with this prefix is Gateway B. 
Y: gateway B 
Z: gateway B 

G: gateway B 30 
At gateway B (36) 

FIB (prefix: next hop on shortest path) 

W: the next gateway on the path to the subnet 
containing addresses with this prefix is Gateway 
A. 

X: gateway C 35 
Y: gateway D 
Z: gateway £ 
G: gateway E 
At gateway C (39) 

FIB (prefix: next hop on shortest path) 

address prefix X: addresses with this prefix are located *q 

in the local subnet (32) 
W: the next gateway on the path to the subnet containing 

addresses with this prefix is Gateway B. 
Y: gateway D 
Z: gateway B 
G. local subnet (32) 
MURT (groupid: associated prefixes) 45 
groupid G: the prefixes associated with this groupid are 
XZ 

At gateway D (38) 

FIB (prefix: next hop on shortest path) 

address prefix Y: addresses with this prefix are located 

in the local subnet (33) 50 
W: the next gateway on the path to the subnet containing 

addresses with this prefix is Gateway B. 
X: gateway C 
Z: gateway B 
G: gateway C 

At gateway E (37) 55 
FIB (prefix: next hop on shortest path) 

address prefix Z: addresses with this prefix are located 

in the local subnet (34) 
W: the next gateway on the path to the subnet containing 

addresses with this prefix is Gateway B. 
X: gateway B ^ 
Y: gateway B 
G: local subnet (34) 
MURT (groupid: associated prefixes) 

groupid G; the prefixes associated with this groupid are 
X£ 

In this example, "G" is the groupid of a multicast group 65 
which has members in subnetworks X (32) and Z (34), 
and it is assumed that only gateways C (39) and £ (37) 
maintain MURT entries for groupid G. Hence, all other 



gateways treat G like a unicast address (i.e., according 
to the existing IDRP procedures), and therefore main- 
tain a single entry for G in their FIBs. The fact that 
multiple gateways advertise a path to G (gateways C 
and E in the example) is not a problem, since IDRP 
allows for this. However, gateways only store routing 
information (in the FIB) for the best path for a given 
prefix. For example, gateway B (36) has a FIB entry of 
gateway E (37) associated with G rather than gateway 
C (39). This could have been reversed, but in any event 
only one of the paths is stored in the FIB. 

MPTN gateway A (35) receives a multicast packet 
addressed to G from subnetwork W (31). it does not 
have a MURT entry for G, so it routes the packet based 
on the FIB entry for G (to gateway B) with the follow- 
ing fields: 

destination =G 

target subnetworks =not set 

data as specified in the original multicast packet 
Note that the target subnetworks field is not set since 
the MURT entry for G is not available. 

Gateway B (36) receives the packet, and since it also 
does not have a MURT entry for G, routes the packet 
based on its FIB to gateway E (37) with the following 
fields: 

destination =G 

target subnetworks =not set 

data as specified in the original multicast packet 

Gateway E (37) is attached to subnetwork 2 which 
has members in group G, and therefore it has a MURT 
entry for G. The MURT indicates that the packet is to 
be multicast in subnetworks with prefixes X and Z. 
Since subnetwork Z (34) is attached, it multicasts the 
packet into that subnetwork. Since the FIB entry for 
subnetwork X (32) is gateway B (36), an MPTN mul- 
ticast packet is sent to gateway B with the following 
fields: 

destination =G 

target subnetworks =X 

data as specified in the original multicast packet 

Since the target subnetworks Fields is now set, gate- 
way B (36) forwards the packet based on that field 
(contrast the routing decision made here to that made at 
gateway B above). Thus, since the FIB entry for subnet- 
work X (32) is gateway C (39), it forwards the MPTN 
multicast packet to gateway C with the following fields: 

destination =G 

target subnetworks =X 

data as specified in the original multicast packet 
Finally, gateway C (39) multicasts the packet to grou- 
pid G in subnetwork X (32) to which it is attached. 

Note that in this example the packet was routed 
through gateway B (36) twice; once with the target 
subnetworks field not set, and once with it set. Thus, the 
savings in storage for not maintaining the MURT 
entries at gateways A, B, and D (35, 36, and 38) come at 
the expense of suboptimal routing behavior for mul- 
ticast packets. 

MPTN Use of Multicast 

As noted previously, MPTN relies on multicasting to 
support multicasts by applications using MPTN, and to 
support MPTN control algorithms. These problems and 
the manner in which they are solved are described in 
this section. 

Existing routing protocols require that all nodes 
whose addresses have a common prefix be located in a 
single subnetwork. In that way, the prefix uniquely 
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identifies the subnetwork, and operations involving 2. Whenever a gateway becomes aware of the exis- 

nodes with the given prefix can be entirely performed tence of other gateways attached to the same island 

within that subnetwork. This is illustrated in FIG. 4. (which it must in order to implement the existing rout- 

MPTN allows nodes in different subnetwork to have ing protocols), it examines the addresses of all such 

the same address prefix. Thus, such a prefix does not 5 gateways and uses the smallest such address (which 

uniquely identify a particular subnetwork, and opera- might be its own) as the unique prefix for the split netid. 

tions involving nodes with this prefix may have to be Since all gateways will execute this algorithm, they will 

distributed over multiple subnetworks. This is illus- converge to using the same address as the prefix to 

trated in FIG. 5. This is referred to as a "split netid", uniquely identify this island. 

since ''netid" is a synonym for address prefix, and 10 ™ s ste P De repeated whenever a gateway is 

"split" implies that the nodes with the given netid are a <* ded or dropped from the set of gateways attached to 

split up among different subnetworks. The subnetworks the local s P ht netid ^land. 

containing nodes in the split netid are called "islands" of ™ s method provides valid unique prefixes for split 

that split netid. Thus, FIG. 5 illustrates a split netid with netid « lands » the case where ^ or more disjoint 

3 islands. Support of such split netids has implications 15 are joined into one island, or when a single island 

on the following MPTN operations: » dynamically split into several islands. The algorithm 

1. Packets multicast by MPTN users to nodes in a h completely distributed and is guaranteed to result in a 
split netid must be delivered to all subnetworks contain- cor 5 e ? assignment ^of unique prefixes to gateways at- 
ing such nodes. toched to s P ht netld lskmds ' 

2. In order to route connections and unicast data- 20 ™ e . F^es ass^iated with a split 
grams to a node in a split netid, MPTN gateways must » caUed a denved netld * ^ 1S illustrated in 
first determine in which island of the split netid the ? ' - . ^ . . _ __ 
destination is located * we see nodes Wltn address prefix X are 

3. Subnetwork protocols that ensure that all addresses „ lo " ted t f" ^° ***** subnetworks. Therefore 3^a 

in use in that subnetwork are unique must be extended 25 net,d ' » a ***** MPT J? 

« . , . - ..^ ... n , gateways attached to those subnetworks. Gateway G 

to all islands or a split netid, since nodes with the same 7™ .7. , . u j * * • 1 j r 

j j , . . \ . , • * Al _ (62) is the only gateway attached to the top island of 

address could exist there due to the use of the same * v T * *iT * •* 1 1 j j v n *v 

, , - split netid X. It therefore uses its local address X.7 as the 

a ess pre . ... ._, . . . unique prefix to be associated with groupid X. Gate- 
In order to supped split netids, the multicast pro to- ^ H ^ ^ j (64) m iQ th / lower island 
cols described m this invention are used. In particular of ^ Ht ^ since m k Iess ^ 
the address prefix common to the nodes in the spht neud j, fi ^ 8 k less than X9) m both use x g M 

* gT ° Upid ' ^ gT0UI !I d ? the unique prefix to be associated with groupid X. Using 

with all MPTN gateways adjacent to all islands of the ^e protocols of ^ 

invention, Gateway F (61) builds 

spht netid. Thus, the groupid identifies the group of all 35 ^ aiustrat ed FIB and MURT table entries associated 
islands of the split netid. User datagrams and connection w j tn tne ^dress pre fix X 

requests will be received that specify a destination ad- Using ^ multicast protocols from the previous sec- 
dress that begins with the split netid prefix (Lc, the tjons, and tile procedure for mapping split netids to 
groupid), since users will want to communicate with gr0U pids and derived netids in this section, it is possible 
resources m that split netid. MPTN control packets will 40 t0 SU p por t split netiris in MPTN. 
be addressed to the groupid in order to communicate jf ^ MPTN user's packet is to be multicast to all 
with one gateway attached to each island of the split nodes ^th pre f lx x , the packet can be distributed to all 
netid, as explained below. As with other groups, each islands of the split netid using the procedures of the 
group member (i.e„ each island) also requires a unique previous sections since X is an entry in the MURT. In 
prefix that will be associated with the groupid in the 45 ^ same waV) flows whicn are part of subnetwork 
MURT. This is obtained as follows. name management protocols can be multicast to all pads 

Each gateway attached to a spht netid has an address Q f a sp ii t netid. 
in that subnetwork which is globally unique (this global if a connection or unicast datagram is to be sent to a 
uniqueness is guaranteed by the subnetwork protocols). node with prefix X (say X.3 in the example in FIG. 6), 
If this gateway is the only gateway attached to a partic- 50 an additional protocol is required, which forms another 
ular island of the split netid, it may use its own address par t of this invention. An MPTN gateway that is re- 
in that subnetwork as the unique prefix for the island. quired to route a unicast packet or connection based on 
Since all routing protocols in the class relevant to this an address prefix which appears in the MURT uses this 
invention (e.g., IDRP, IP, OSPF, OSI IS-IS) require procedure. 

that gateways communicate to exchange routing infer- 55 1. Using the multicast method described in this inven- 
mation, gateways will automatically have contact with tion, a LOCATE request is distributed to one MPTN 
all other gateways attached to the same island of the gateway attached to each island of the split netid. A 
split netid (i.e., all of those gateways with which it parameter of the LOCATE is the specific address 
exchanges routing information through that subnet- which is the target of the original unicast packet (i.e,, 
work). Thus, gateways are aware when multiple gate- 60 the resource that is to be located). Thus in the example, 
ways are attached to the same island of a split netid, and gateway F (61) multicasts a LOCATE to gateways G 
also when gateways are added or removed from the set (62) and H (63) to determine the location of the resource 
attached to a split netid island. X.3. 

The method for selecting a unique prefix to associate 2. Each gateway that receives such a LOCATE re- 
with an island of a split netid is as follows: 65 quest searches the attached subnetwork (using the na- 

1. When a gateway is initially activated, it assumes tive protocols of that subnetwork, or MPTN protocols) 
that its own address will be used as the unique prefix for to determine if the target resource is actually located in 
the split netid island to which it is attached. that island of the split netid. In the example, gateway G 
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(62)discovers that X.3 is located in the attached subnet- 3. The method of claim 2, wherein the receiving 

work, while gateway H (63) is not able to locate X.3. stations defined by the group identifier are located in 

3. All gateways that received the LOCATE return a different subnetworks. 

response to the MPTN gateway that initiated the search 4, The method of claim 1, wherein the multicast rout- 
that includes the unique prefix of the responder, and a 5 ing table maintained in a particular gateway node in- 
flag which indicates if the resource was found or not In eludes information of only those receiving stations that 
the example, gateway G (62) returns a response to gate- can be reached via said gateway node, 
way F (61) that includes its unique address prefix X.7, 5. The method of claim 2, wherein the multicast rout- 
and a flag that indicates that the resource was found. ing table (MURT) maintained in a particular gateway 
Gateway H (63) returns a result indicating that the 10 node includes information of those receiving stations 
resource was not found. that can be reached via said gateway node. 

4. As soon as a positive response to the search is 6. The method of claim 3, wherein the multicast rout- 
obtained, gateway F (61) is able to route the unicast m S maintained in a particular gateway node in- 
message or connection to the proper destination. The eludes information of those receiving stations that can 
header of that request must indicate to which gateway 15 be reached via said gateway node. 

the request is being routed (X.7 in the example) so that 7 - ^ m <*kod of claim 1, wherein only those gate- 
all gateways can forward the request. The header must wav . nodes which connected to possible sources of 
further include the address to which the request is des- multicast messages maintain a multicast routing table of 
tined (X.3) so that the final gateway will be able to route addressable receiving stations, 
it through the subnetwork containing the destination. 20 8 " ^ me *°* of clami * w j hercm om > ^ 

It is important for gateways that cannot locate a par- way nodes whl <* « connected to possible sources of 

ticular resource to send a negative response to a LO- mamtain a . multlcast routm * of 

CATE request. Otherwise, in the case where the target ^J^^TT^ 9 ^^ • i u 

resource does not exist (e.g., a user attempts to send a „ 9 " ™ e me * 0< ? of claun 3 > m on J v ^ ate : 

message to X.5 which does not exist), the gateway that 25 wa * nod ™ whlch m * possible sources of 

needs to route the request would wait forever for a T 1 ^ m ™*™ » multlcast routu * tobte of 

r x j -r ^ j the addressable receiving stations, 

response Instead, tf a negative response is recerved w ^ metho(J of ^ 

from each gateway, .t knows hat the resource in ques- nodes wnich „. connected to possible soured of 

tion is unreachable and it can therefore reject the ongi- - A _„w; . _ • * • _ i«s * ^ iV i c 

J & 30 multicast messages maintain a multicast routing table of 

n _5^ ues " . . . - , - the addressable receiving stations. 

This terminates the description of the preferred em- u Xhe method of claim 5 wherein only ^os* gate . 

bodiments. Of course, numerous variations of the given nodes which „ connected to ible S0UIces of 

examples are possible, still within the scope of the in- multicast messages maintain a multicast routing table of 

vention as claimed. 35 ^ addressable receiving stations. 

We claim: . ^ 12. The method of claim 6, wherein only those gate- 

1. A method for multicasting a message from a send- way nodes which „ connected to possible sources of 
ing station to a plurality of receiving stations within a mu i ticast messages maintain a multicast routing table of 
conventional unicast message transmission network the addressable receiving stations. 

using existing protocols, said network containing a plu- 40 13 ne met hod of any one of claims 2, 3, 5, 6, 8, 9, 11, 
rality of subnetworks and a plurality of gateway nodes or 12> whe rein the group identifier and the correspond- 
connecting, and acting as entry ports to, said subnet- pre flxes are transmitted to the gateway nodes to- 
works, said method comprising: gether with conventional routing information, 
distributing multicast group information by each sub- 14 . A system for multicasting a message from a send- 
network to each connected gateway node, said 45 fog sta tion to a plurality of receiving stations within a 
group information identifying each group of re- conventional unicast message transmission network 
ceiving stations reachable in said subnetwork; using existing protocols, said network consisting of a 
building and mamtaining a multicast routing table in plurality of subnetworks connected by a plurality of 
each gateway node, said routing table containing gateway nodes, said system comprising: 
said group information to enable the routing of 50 means at each of said plurality of gateway nodes for 
multicast messages to each said group of receiving routing multicast messages to a group of receiving 
stations, said multicast routing table having a single stations, said routing means including a routing 
entry for each said group; table having a single entry for each addressable 
transmitting said multicast message with a group group of receiving stations, 
identifier carried in a header part of said multicast 55 wherein each multicast message to be transmitted 
message defining an addressed group of receiving carries a header that contains information defining 
stations; and the addressable group of receiving stations to re- 
in each gateway node, reading and interpreting said ceive said each multicast message, and, 
group identifier transmitted in said multicast mes- means in each gateway node for interpreting, com- 
sage to direct forwarding of said multicast message 60 paring and modifying the header of said each mul- 
to said addressed group of receiving stations. ticast message. 

2. The method of claim 1, wherein the group informa- 15. The system of claim 14, wherein said plurality of 
tiori in the multicast routing table at each gateway node subnetworks are of different types and use different 
contains at least one prefix corresponding to each group message transmission protocols. 

identifier identifying each subnetwork in which the 65 16. The system of claim 15, wherein only a subset of 

addressed group of receiving station(s) is located, and said plurality of subnetworks is equipped to support 

wherein said header part of each said multicast message multicasting, 

contains said corresponding prefix. ***** 
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